As data networks have been growing in equipment numbers, so has the complexity and diversity of the equipment connected. This has caused an increase in the difficulty and cost of monitoring, management and configuring data networks.
Standardized tools are needed to control these types of networks, tools that can be used with equipment from different manufacturers, including routers, switches and other telecommunication equipment, as well as computers or other final network equipment such as PDAs and mobile telephones. Hereinafter, the terms host or device will be used to refer to data network equipment.
As a response to this need, the “Simple Network Management Protocol” or SNMP was developed, which is a tool that allows the maintenance and configuration of network equipment from different manufacturers.
SNMP is a set of standards for managing network equipment. SNMP was adopted years ago as a standard for TCP/IP networks and has become the most widely used tool for managing networks and network-connected devices.
In 1991, a supplement was added to the SNMP, called Remote Network Monitoring (RMON). RMON extends SNMP capacities to include the management of local area networks (LANs) as well as managing the devices connected to those networks.
There are many updates and new versions of the SNMP protocol. In 1995 an update was published called SNMPv2. In 1998 the last version of this set of standards was published, called SNMPv3, which improved aspects related to security.
An SNMP management system may comprise the following elements:
At least one control or management station, traditionally called “SNMP Manager” or “management station”. Henceforth, the term “control station” will be used to refer to an SNMP Manager or to other types of management systems.
Several nodes (potentially many), each of which uses one application, traditionally called an SNMP agent, to communicate with the control station. The SNMP agent has access to the configuration information for its node and can send and receive messages from the control station. Other types of management systems may use different types of agents.
A communications protocol to communicate between the control station and the SNMP agents. Other types of management systems may use other types of protocols.
SNMP agents manage the resources for nodes by using objects that represent these resources. The object is generally a variable with data that represents an aspect of the managed node. The set of objects for a specific network node is called the “Management Information Base” or MIB.
MIBs are standardized for each type of network device. For example, a particular MIB is used for various switches from different manufacturers.
An SNMP control station monitors the operation of equipment by obtaining the value of the objects found in the equipment's MIB. To do so, the SNMP control station communicates with the SNMP agent and requests that information.
An SNMP control station can also modify values from the objects found in this equipment's MIB, sending a message to the SNMP agent for that equipment so it modifies the values.
MIBs are specifications that contain definitions to manage and maintain information for a specific type of network equipment so that network equipment, even being from different manufacturers, can be monitored, configured and controlled remotely.
The rules that set the language used to write MIBs are defined in specifications RFC2578 (McCloghrie et al., Internet Engineering Task Force, Request for Comments 2578, “The structure of Management Information Version 2, SMIv2”, April 1999, currently available on the Internet at http://www3.tools.ietf.org/html/rfc2578) and specifications RFC2579 (McCloghrie et al., Internet Engineering Task Force, Request for Comments 2579, “Textual Conventions for SMIv2”, April 1999, currently available on the Internet at http://www3.tools.ietf.org/html/rfc2579).
SMIv2 uses a small part of the instructions from a language called Abstract Syntax Notation One (ASN.1).
ASN.1 is a formal, standardized language and is important to the SNMP protocol for many reasons. Firstly, it is used to specify data syntaxes. It is also used to define SNMP protocol messages, also called “Protocol Data Units” (PDUs). Lastly, it is used to define the MIB.
Although SNMP is the most widely used protocol to manage network devices, It has a few disadvantages.
The first disadvantage is the complexity. An overall view of the operation of SNMP protocols and the equipment which implements it is described in specifications RFC3411 (D. Harrington et al., Internet Engineering Task Force, Request for Comments 3411, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks”, December 2002, currently available on the Internet at http://www3.tools.ietf.org/html/rfc3411). In Section 10, references for these RFC3411 specifications list another 22 RFC documents (“Request for Comments”) that describe this operation of the SNMP protocol.
A sample of the complex nature of the SNMP protocol is the free software project “Net-SNMP” which is available at http://net-snmp.sourceforge.net/ which provides the source code for an SNMP agent. This source code may be downloaded for free and the available version in January 2008 for that SNMP agent totals 878 source code files using the C programming language (files ending in “c” or “h”) incorporating a total of 316,435 lines of code.
This complexity is a problem for two reasons. The first problem is financial due to the time, knowledge and human resources needed to implement an SNMP agent. The second problem is technical due to the storage capacity and process capacity required by devices that have to incorporate SNMP agents. This technical resource problem is not a problem for equipment such as routers, switches or computers that have enough processing capacity to incorporate SNMP agents. However, this technical complexity is a problem for many other items of equipment that have less processing capacity and where also power consumption can be an important factor in their design, such as for example in mobile phones or in systems that are controlled by microcontrollers with limited memory and processing capacity.
Another limitation of the SNMP protocol is that the SNMP control station must establish a direct communication with every SNMP agent. This gives rise to many problems, as it increases the number of SNMP agents it must control. The first problem is that the SNMP control station can manage a limited number of SNMP agents and may not have sufficient processing capacity if the number of agents is many thousands or hundreds of thousands. The second problem is the amount of traffic generated in the network due to SNMP messages between the SNMP control station and SNMP agents as the number of managed devices grows.
A technology that could be used to solve these SNMP limitations is multicast technology. There are some scientific studies that investigate the use of multicast technology using the SNMP protocol.
The following document describes the practice of sending multicast packets between SNMP agents. Ehab Al-Hshaer, Yongning Tang. “Toward Integrating IP Multicasting in Internet Network Management Protocols”. Computer Communications, Volume 24, Number 5, 15 Mar. 2001, pgs. 473-485, Publisher: Elsevier, currently available on the Internet on http://citeseer.ist.psu.edu/447658.html.
Multicast technology makes it possible to send data from only one source to many recipients over a data network, without having to establish unicast communications, which means a one-on-one communication between the source and each of the recipients. To do so, the source sends data, in the form of data packets, to only one address related to a multicast group to which the equipment interested in being recipients of the data may subscribe. This address, called the multicast address or the multicast group address, is an IP address (Internet Protocol) selected within a range that is reserved for multicast applications. Data packets that have been sent by the source to the multicast address are therefore replicated by the different network routers so that they reach the recipients that have joined the multicast group.
The messages exchanged between a host and the closest router to manage membership to a multicast group use the IGMP protocol (Internet Group Management Protocol) or the MLD (Multicast Listener Discovery) protocol, according to whether or not the router works with version 4 (IPv4) or version 6 (IPv6) of the IP protocol (Internet Protocol), respectively.
When there is a proxy between the host and the router, the proxy also uses the IGMP/MLD protocols to exchange with the host, the closest router or other intermediate proxy, the multicast group membership messages. In these cases, the proxy can receive from different hosts requests to subscribe to or to unsubscribe from a multicast group, and it assembles them to thus reduce IGMP/MLD message traffic it sends to the router. Hereinafter, the generic term IGMP proxy will be used to designate a proxy using the IGMP/MLD protocols.
In addition, routers exchange messages with one another for the purpose of defining the routing which allows efficiently routing the data from the sources to the hosts that have subscribed to a multicast group. To that end, the routers use specific protocols, including the very well known PIM-SM (Protocol Independent Multicast-Sparse Mode).
All the mentioned protocols are defined and documented by the Internet Engineering Task Force (IETF).
The IGMP protocol version currently being used is IGMPv3, which is described in the RFC 3376 specifications published on line by the IETF (B. Cain et al., Engineering Task Force, Network Working Group, Request for Comments 3376, October 2002; currently available at Internet address http://tools.ietf.org/html/rfc3376).
With regard to the MLD protocol, the version currently being used is MLDv2, which is described in the RFC 3810 specifications published on line by the IETF (R. Vida et al., Engineering Task Force, Network Working Group, Request for Comments 3810, June 2004; currently available at Internet address http://tools.ietf.org/html/rfc3810).
The operation of an IGMP proxy is described in the RFC 4605 specifications published on line by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4605, August 2006; currently available at Internet address http://tools.ietf.org/html/rfc4605).
The PIM-SM protocol used for the communication between routers is described in the RFC 4601 specifications published on line by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4601, August 2006; currently available at Internet address http://tools.ietf.org/html/rfc4601).
Multicast technology was initially implemented primarily to be applied to the many-to-many communication model, known as ASM (Any Source Multicast), in which many users communicate with one another and any of them can send data and also receive data from everyone else. A typical ASM application is multiparty calling via Internet.
Multicast technology was then implemented to be applied to the one-to-many communication model known as SSM (Source Specific Multicast), in which a single source sends data for many recipients. Radio and television via Internet are SSM applications. This is why SSM is currently very interesting.
In earlier IGMP protocol versions, a host could not choose the data sending sources it wanted to subscribe to within a multicast group, rather the host could only subscribe to or unsubscribe from the group for all the sources. The messages a host sent to a router were very simple: Join (G) to receive traffic from the multicast group G and Leave (G) to stop receiving it. Therefore, earlier IGMP protocol versions did not allow SSM, where hosts can choose the multicast data sources.
The possibility that the hosts could choose the sources within a multicast group was introduced in the IGMPv3 version of the IGMP protocol to allow SSM. To that end, a host can send IGMP messages containing data blocks referred to as Group Record in which the host defines the sources from which traffic is to be received for each multicast group. These Group Record data blocks in an IGMP message can be of several types:
An INCLUDE type Group Record data block containing information on source IP addresses from which the host wishes to receive data sending. According to the terminology of the RFC 3376 specifications, the sources chosen by means of an IGMP message containing an INCLUDE type Group Record are referred to as INCLUDE sources.
An EXCLUDE type Group Record data block, containing information on source IP addresses from which the host does not wish to receive data sending. In this case, it is interpreted that the host wishes to receive data sent by all the sources of said multicast group except the sources indicated as excluded in the message. According to the terminology of the RFC 3376 specifications, the excluded sources by means of an IGMP message containing an EXCLUDE type Group Record are referred to as EXCLUDE sources.
For clarity's sake, the term INCLUDE message will be used hereinafter to designate an IGMP message containing an INCLUDE type Group Record, and the term EXCLUDE message will be used hereinafter to designate an IGMP message containing an EXCLUDE type Group Record.
It was decided in the IGMPv3 version that each network interface could operate for each multicast group only in one of the following two modes, being able to switch from one to the other: an INCLUDE mode in which the network interface defines an INCLUDE source list or an EXCLUDE mode in which the network interface defines an EXCLUDE source list.
Each network interface and multicast group has a state record storing the information on said interface and group and said state record contains a field referred to as filter-mode which can only be of the INCLUDE type, containing only INCLUDE sources, or of the EXCLUDE type, containing only EXCLUDE sources. The rules that are transcribed below are applied when the network interface record must result from the combination of different records:
Rule 1. If any of the data sources of a group G1 is EXCLUDE, then the network interface will have an EXCLUDE filter-mode for the group G1 and the source list of the network interface is the intersection of the EXCLUDE source lists minus the sources of the INCLUDE lists.
Rule 2. If all the sources are INCLUDE type sources, then the network interface will have an INCLUDE filter-mode for the group G1 and the source list is the union of all the INCLUDE sources.
These rules are applied in a network interface of equipment operating as an IGMP proxy and receiving INCLUDE messages or EXCLUDE messages from different hosts or from different IGMP proxies located on the downstream side of the network interface (i.e. in the direction going from the router to the hosts). These same rules are also applied in a network interface of equipment, such as a personal computer for example, provided with several sockets receiving different INCLUDE source or EXCLUDE source requests from different applications.
Channel (S, G) is used hereinafter, and according to the common nomenclature in SSM technology, to refer to the sending of source S of the multicast group G.
In the current state of the art, to save memory, routers using the IGMPv3 protocol store only the minimum multicast traffic information that they must transmit. This minimum information consists of storing, for each network interface of the router and multicast group, a state reflecting if, for a specific channel (S,G) or multicast group (*,G) there is at least one host interested in receiving said multicast traffic.